-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Factor-out logic to determine the path of the precompilation cache file. #33173
Conversation
BSD failure is unrelated ( |
You have to be a bit careful here because after my PR we now have a "pool" of precompilation files and if any one of those matches, we will use that one. So is the plan for CUDAdrv.jl and LLVM.jl to remove all precompilation in that pool for the relevant packages? Isn't it possible to use |
Does it matter if I remove the current one or the entire pool? The removal happens during
That's an indirect alternative, yes, but IMO isn't much nicer than just directly removing the precompilation cache. Besides, avoiding global state (a tracked dummy file) is what lead me to doing all this work during precompilation in the first place, so I'd rather avoid re-introducing that. We kind-of used to do that by calling into |
I am not sure exactly how the deletion is done so everything might be fine. I was just thinking of the case where you had a precompile from another environment that is valid even for the current project. So if you delete the precompilation file that the current environment would use, there might still be one in the pool that matches and you don't get a recompilation. But maybe that worry is not applicable here. |
Pretty sure it's fine how we do it, since |
CUDAdrv.jl and LLVM.jl need to be able to wipe the precompilation cache file in order to force recompilation, since there's global state that depends on resp. the CUDA and LLVM library version. After #32651, that became a little cumbersome, so factor out the logic to get the path to the current cache file.